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CLAIM AMENDMENTS 
This listing of claims will replace all prior versions, and listings, of claims in the 
application: 

Listing of Claims: 

Claims 1-10 (Canceled). 

Claim 11 (previously presented): A method for interworking protocols to 
provide a performance feature in a communication network, comprising: 

providing a first protocol that controls a first subscriber; 

providing a second protocol that controls a second subscriber; 

disconnecting an established data channel between the first subscriber 
and the second subscriber by deactivating a transmitter for the second 
subscriber; 

receiving a notification of a call progress for the performance feature in 
accordance to the first protocol; and 

interworking the notification into the second protocol depending on a 
"held" status of the second subscriber. 

Claim 12 (previously presented): The method according to claim 1 1 , 
wherein the performance feature is a large conference feature in 
accordance to the International Telecommunications Union (ITU) standard 
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Q. 734.1 or a small conference feature in accordance to the ITU standard 
Q.734.2, and 

wherein the disconnect according to the first protocol is produced by 
interrupting the established data channel in a central transmission mode. 

Claim 13 (previously presented): The method according to claim 12, 
wherein the deactivation occurs when a third subscriber is added to the 
conference or at least one of the first subscriber, the second subscriber, and 
the third subscriber is isolated from the conference. 

Claim 14 (previously presented): The method according to claim 13, 
wherein interworking occurs when the transmitter is deactivated. 

Claim 15 (previously presented): The method according to claim 28, 
wherein an ISUP CPG notification with a generic notification parameter 

"Isolated" is mapped into a SIP message with a deactivate attribute line, and 

wherein an ISUP CPG notification with a generic notification parameter 

"Reattached" is mapped into a SIP message with an activate attribute line or 

without an attribute line. 

Claim 16 (previously presented): The method according to claim 28, 
wherein the SIP message is an "INVITE" when a call state is in an 
answered state, and 
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wherein the SIP message is an "UPDATE" if the call state is in a "before 
answer" state. 

Claim 17 (previously presented): The method according to claim 28, 
wherein interworking occurs after a SIP message with a deactivate attribute line 
or no attribute line has been sent. 

Claim 18 (canceled). 

Claim 19 (previously presented): A media gateway controller for an 
interworking of protocols for a conference feature within a communication 
network, comprising 

an ISUP protocol message for controlling a first subscriber; 

a SIP protocol message for controlling a second subscriber; 

a protocol converter from the ISUP protocol message to the SIP protocol 
message, and 

a status of a transmitter for the second subscriber; 

wherein the status is active or deactive, and wherein when the ISUP 
protocol message is a call progress notification with "Conference established" 
or "Conference disconnected" and the status is deactive, the SIP protocol 
message created by the converter indicates to activate the transmitter, 

wherein when the ISUP protocol message is a call progress notification 
with "Isolated" the SIP protocol message created by the converter includes a 
deactivate attribute of "a=sendonly" or "a=inactive", and 
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wherein the status is deactive after a prior ISUP message is converted 
to a prior SIP message having a deactivate attribute of "a=inactive" or 
"a=sendonly" or to a SIP invite (0.0.0.0) message or the prior SIP message 
does not have "a=recvonly" or "a=sendrecv". 

Claim 20 to 22 (canceled). 

Claim 23 (previously presented): The controller according to claim 19, 
wherein the status is deactive after a prior ISUP message is converted to a 
prior SIP message having a deactivate attribute of "a=inactive" or "a=sendonly" 
or the prior SIP message does not include an activate attribute. 

Claim 24 (previously presented): The controller according to claim 19, 
wherein when the ISUP protocol message is a call progress notification with 
"Reattached" the SIP protocol message created by the converter includes an 
activate attribute. 

Claim 25 (currently amended): A computer readable medium operable 
to execute the following on a processor for interworking protocols to provide a 
conference feature in a communication network, comprising: 

deactivating a transmitter for an established data channel between a first 
subscriber and a second subscriber when adding a third subscriber to the 
conference or isolating the third subscriber from the conference, 

wherein a first protocol controls the first subscriber, and 
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wherein a second protocol controls the second subscriber; 

receiving a notification of a call progress for the conference feature in 
accordance to the first protocol; 

mapping the notification into a message in accordance to the second 
protocol; and 

sending the message in accordance to the second protocol to the 
second subscriber, 

wherein the first protocol is ISUP and the second protocol is SIP, 
wherein an attribute line is selected from the group consisting of: 
"a=sendonly", "a=recvonly", "a=sendrecv", and "a=inactive", 

wherein aB a deactivate attribute line is "a=sendonly" or "a=inactive", 
wherein an activate attribute line is "a=sendrecv" or "a=recvonly", 
wherein an ISUP call progress (CPG) notification with a generic 
notification parameter "Conference established" is mapped into a SIP message 
with an activate attribute line or without an attribute line if a prior SIP message 
having a deactivate attribute line or a SIP invite(0. 0.0.0) message has been 
sent, 

wherein an ISUP CPG notification with a generic notification parameter 
"Conference disconnected" is mapped into a SIP message with an activate 
attribute line or without an attribute line if a prior SIP message having a 
deactivate attribute line has been sent, 

wherein an ISUP CPG notification with a generic notification parameter 
"Isolated" is mapped into a SIP message with a deactivate attribute line, and 
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wherein an ISUP CPG notification with a generic notification parameter 
"Reattached" is mapped into a SIP message with an activate attribute line or 
without an attribute line. 

Claim 26 (canceled). 

Claim 27 (previously presented): The computer readable medium 
according to claim 25, 

wherein the SIP message is an "INVITE" when a call state is in an 
answered state, and 

wherein the SIP message is an "UPDATE" if the call state is in a "before 
answer" state. 

Claim 28 (previously presented): A method for interworking protocols to 
provide a performance feature in a communication network, the method 
comprising: 

providing a first protocol that controls a first subscriber; 

providing a second protocol that controls a second subscriber; 

disconnecting an established data channel between the first subscriber 
and the second subscriber by deactivating a transmitter for the second 
subscriber; 

receiving a notification of a call progress for the performance feature in 
accordance to the first protocol; and 

interworking the notification into the second protocol 
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wherein the performance feature is a large conference feature in 
accordance to the International Telecommunications Union (ITU) standard 
Q. 734.1 or a small conference feature in accordance to the ITU standard 
Q.734.2, 

wherein the disconnect according to the first protocol is produced by 
interrupting the established data channel in a central transmission mode, 

wherein the deactivation occurs when a third subscriber is added to the 
conference or the subscriber is isolated from the conference, 

wherein interworking occurs when the transmitter is deactivated , 

wherein the first protocol is ISUP and the second protocol is SIP, 

wherein an attribute line is selected from the group consisting of: 
"a=sendonly", "a=recvonly", "a=sendrecv", and "a=inactive", 

wherein an deactivate attribute line is "a=sendonly" or "a=inactive", 
wherein an activate attribute line is "a=sendrecv" or "a=recvonly", 

wherein an ISUP call progress (CPG) notification with a generic 
notification parameter "Conference established" is mapped into a SIP message 
with an activate attribute line or without an attribute line if a prior SIP message 
having a deactivate attribute line or an SIP invite(0. 0.0.0) message has been 
sent, and 

wherein an ISUP CPG notification with a generic notification parameter 
"Conference disconnected" is mapped into a SIP message with an activate 
attribute line or without an attribute line if a prior SIP message having a 
deactivate attribute line has been sent. 
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Claim 29 (previously presented): The method according to claim 15, 
wherein interworking occurs after a SIP message with a deactivate attribute line 
or no attribute line has been sent. 

Claim 30 (previously presented): The method according to claim 16, 
wherein interworking occurs after a SIP message with a deactivate attribute line 
or no attribute line has been sent. 

Claim 31 (currently amended): The controller according to claim 23, 
wherein when the ISUP protocol message is a call progress notification with 
"Reattached" the SIP protocol message created by the converter includes a an 
activate attribute. 

Claim 32 (previously presented): The controller according to claim 19, 
wherein the SIP message is an INVITE and includes an activate attribute 

of "a=sendrecv" or "a=recvonly" or 

wherein the SIP message is an UPDATE and includes an activate 

attribute of "a=sendrecv" or "a=recvonly". 
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